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SYSTEM AND METHOD FOR BUILDING AN APPLICATION ON A COMPUTING 
DEVICE WHICH INCLUDES AN ENVIRONMENT-CONTROLLING PROCESS 

CROSS-REFERENCE TO RELATED APPLICATIONS 
[0001] None. 

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR 

DEVELOPMENT 

[0002] None. 

BACKGROUND OF THE INVENTION 

1 . Field of the Invention 

[0003] The present invention relates to the process of creating a build on a computing 

device. More specifically, the present invention involves the use of files that are checked out of 
a version control system. These files enable the user to control server class configurations in the 
computing device from a file on a PC. The files enable the user to dynamically configure server 
classes with respect to the particular environment in which it is desired that the server class run 
in, and delete previous server-class configurations in order that corruption, which might be due 
to preexisting server classes in the pathway, is prevented. 

2. Description of the Related Art 

[0004] Version control systems, also known as source control tools, are a component of 

configuration management. The purpose for these tools is to enable a computer programmer to 
take a "snapshot" of a development process to be recovered at some stage in the future. 
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Recovery of the snapshot usually occurs when computer program application development has 
moved on past the snapshot time. 

[0005] If a source control tool is not used, and software is released for use in the field 

without maintaining a version, problems may arise when later software releases are made. If the 
program with the later release contains a bug that prevents the software from being useable, 
without the use of a version controlling system, there is no way to recover specifically which 
version in which the bug exists. 

[0006] Bugs usually develop at the point that software is modified. Oftentimes the bug is 

not recognized until long after the modification is made. Therefore, version control tools enable 
programmers to easily retrieve old versions to see the point and time at which the bug entered the 
application's development. 

[0007] One common version control system known to those skilled in the art is known as 

"CVS." CVS stores all of the versions of each file which comprises an application. This is 
done, however, in a manner in which only the differences between the versions of each file are 
stored. If a number of different programmers are working on the same application, it is very 
easy for different programmers to overwrite the changes of another programmer unless extreme 
caution is taken. CVS overcomes this problem by isolating the different application developers 
by a wall. Each of the programmers works in his or her own directory, and afterwards CVS 
combines all of the changes made by all of the developers when each of them finishes work. 
[0008] The place at which CVS maintains all of the changes to the application is referred 

to as a repository. When a programmer works on an application, working files are checked out 
of the repository. When the programmer is finished, the changes are checked back in. The 
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repository then includes all the changes the programmer has made. It has also recorded when the 
changes were made. 

[0009] Though these widely used source control tools of the prior art have proved to be 

apt for version controlling a number of NT workstations. There is presently ,*however, no way to 
adequately version control applications when they are built onto a larger type of computer. One 
example of such a computer is what is known as and commercially available as a Tandem™. 
[0010] These types of larger computing devices may have a number of servers which 

accomplish its computing functions. They may also have a number of controlling processes, 
each of which manages a particular environment therein. With respect to the Tandem™, a 
Pathmon™ process, or a "pathway" is a controller for a particular environment. 
[0011] Before the present invention, there was no way to ensure that applications being 

tested on a Tandem™ could be easily rebuilt - that the computing objects could be built from 
scratch - and that the objects being tested were kept up to date at all times. 
[0012] Conventionally, one using a PC or in an NT network would have difficulty 

generating a build from CVS onto a Tandem. This process would involve manually checking 
the version out of CVS using a tag. After the version of the application was drawn out of CVS 
onto the PC, it would have to be manually transmitted to the Tandem using a File Transfer 
Protocol (FTP). Once on the Tandem, the process controller for the particular environment 
would have to be manually programmed to build the application in a directory on the Tandem. 
This involves transmitting updates into the process controller. This updates method is 
problematic, because there will be no guarantee that you can build the application again from 
scratch. You will not have the assurance that you can rebuild it if you have to. Additionally, 
knowledge of the vintage server classes will be retained, which would be problematic. If we end 
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the development cycle on a particular application and then later on decide to expand on it, and all 
our environments are gone, then we will be precluded from rebuilding the application from the 
ground up. Additionally, this conventional process is very time consuming and labor intensive. 
[0013] With the prior art techniques, environments were driven off of a process 

controller in the second computing device. The controller on the second computing device was 
given an ED. That ED was then used to set up specific environments. 

[0014] Conventionally, the process controller (e.g., Pathmon™) on the Tandem™ 

contained the server class configurations. You would dump these configurations out onto a file, 
however, that file has established configurations for the particular environment in which its 
server class exists. In order to move it to a new environment, you would have to manually 
change the file so that you could make it work in another environment. This would involve 
reloading and testing the file to make sure that your changes were correct. This is a difficult 
thing to do, because there is nothing in the file that indicates which items are environmentally 
dependent, and which items are not. Thus, the programmer would have to painstakingly search 
and sort. 

[0015] Additionally, this conventional method involves rebuilding the application one 

server class at a time. This involved recoding a file for every server class rebuilt, which is time 
consuming and very detail sensitive. 

[0016] Another disadvantage in the prior art methods of building applications onto the 

large computer involves a lack of adaptability. Working on separate instances of the application 
in separate environments may become problematic where both instances are writing or working 
with the same set of tables. 
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SUMMARY OF THE INVENTION 
[0017] The processes of the present invention overcome this deficiency in the prior art 

source control systems. It ensures that a programmer can be confident that the code pulled out of 
a source control tool may be built on the large computing device with the current configurations, 
or the configurations of a particular version of the application. The code is generated using 
editing software on a first computing device, such as a PC, but stored on a second computing 
device, e.g., a Tandem™, using means which enables the PC to have file access to the directory 
in the second computing device, e.g., Samba™. Then it is checked into the version control 
system along with files that include the appropriate environmental configurations for the 
particular environment in the second computing device into which the application is to be built. 
A particular version of the application is then selected on the first computing device (PC) using a 
conventional source control tool. It is then checked out to a directory on the second computing 
device (Tandem™). The application is then built on a second computing device. The second 
computing device (Tandem™), in one embodiment, has a controller, such as a Pathmon™ 
process. Substantially all server classes associated with the application are then located on the 
pathway of the second computing device, stopped, and then deleted. The selected version of the 
application is then built into an environment in the second computing device. 
[0018] The process of the invention enables the user to (i) control server class 

configurations in the second computing device from a file on the PC; (ii) dynamically configure 
the server classes with respect to the particular environment in which it is desired that the server 
class run in; and (iii) delete previous server-class configurations in order that corruption, which 
might be due to preexisting server classes in the pathway, is prevented. 

[0019] Applicant has accomplished these objectives by developing a file which is 

checked into the version controlling system along with the rest of the application. It contains 
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only parameters which are particular to the environment in the second computing device. This 
file may be edited by the programmer. This enables the programmer to change the 
environmental configurations by simply editing the environmental file on the first computing 
device, and these changes will later be propagated to all the server classes in the second 
computing device that make up the application. 

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS 
[0020] The present invention is described in detail below with reference to the attached 

drawing figures, wherein: 

[0021] FIG. 1 is a schematic showing the components employed in the build process of 

the present invention. 

[0022] FIG. 2 is a schematic showing the different processes existent on the second 

computing device and how these processes may be accessed/activated using the first computing 
device. 

[0023] FIG. 3 shows the XML and XSL files which are checked into the version control 

system and comprise the application. 

[0024] FIG. 4 shows the contents of the environmental-configuration-containing XML 

file. 

[0025] FIG. 5 shows the step in the process of the present invention in which all of the 

server classes in a particular environment in the second computing device are deleted. 
[0026] FIG. 6 shows the step in the process of the present invention in which new server 

classes are added in the environment. 
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DETAILED DESCRIPTION OF THE INVENTION 
[0027] The present invention provides a system and method for using a version control 

tool for building an application from one computing device onto a second computing device. 
The process involves the use of environmental configurations for the second computing device. 
These environmental configurations are checked into the version control tool along with the rest 
of the application. When a scheduled build is compiled on the second computing device, scripts 
are used to employ the environmental configurations to configure servers in the second 
computing device. 

[0028] Programmers will check things into the CVS repository that have been proven to 

work. Unverified things, potentially including bugs, will not be checked in to the repository, and 
thus not automatically rebuilt. Builds may be done on a scheduled basis. In one embodiment of 
the invention, the builds are done from a branch tag. This enables the users to constantly get the 
newest code for the particular area in which programmers are developing. This provides 
numerous advantages not present in the prior art: 

[0029] One advantage provided is that this process makes it easier to identify defects. 

Every interval in which the rebuild process is performed, users will be able to determine if bugs 
exist in the code. This the code will only be able to be built if there is no error that prevents it 
from compiling. If the application was not rebuilt with the newest code (which is known to be 
functional) programmers would not be able to determine if the developed code is what caused 
the compiling error (the bug), or if the bug was present in the pre-existing code. When 
rebuilding occurs on a schedule, the users will know there is a problem, e.g., nightly because it 
will not compile overnight. It will then become apparent that some defect need be corrected. 
[0030] A second advantage is that the process of the present invention keeps the 

application on the second computing device up to date at all times. According to one 
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embodiment of the method, the rebuilds are performed daily. A predetermined interval, or 
intervals are ideal because they will refresh the code on a dependable schedule. This is 
especially advantageous when programmers are testing. For example, if you are testing some 
newly developed parts of the code to see if it works, you want to make sure that the rest of the 
application remains the same day in and day out. Thus, when programmers encounter compile 
errors, they may be sure that it is due to recent development. Debugging efforts, thus, may be 
focused on the newly developed code only. 

[0031] A third advantage is that the process of the present invention enables the code to 

be automatically rebuilt in numerous environments because of its dynamic configuration 
generating functions. The dynamic aspect of the present invention is due to environmental 
configuration generating files which are checked in, and then maintained along with the tagged 
version in CVS. The additions of server classes into a controller in the mainframe enables the 
application to dynamically adapt independent of the parameters of a particular environment. If 
the user is required to manually creating files in the second computing device every time it is 
desired to build the application into a particular environment, time is wasted. The environmental 
configuration generating files, when pulled out of the version control system, enable the 
application to dynamically adapt to the environment. Because of this, multiple test environments 
may be run simultaneously because the configuration adapting files enable the build to 
automatically adapt to the environment. 

[0032] Various technical terms are used throughout this description. A definition of such 

terms can be found in Newton's Telecom Dictionary by H. Newton, 19th Edition (2003). These 
definitions are intended to provide a clearer understanding of the ideas disclosed herein but are in 
no way intended to limit the scope of the present invention. The definitions and terms should be 
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interpreted broadly and liberally to the extent allowed the meaning of the words offered in the 
above-cited reference. For example, whereas some distinguish the World Wide Web (WWW) as 
a subcomponent of the Internet, "web" - as used herein - should not be construed as limited to 
the WWW. Rather, "web" is intended to refer generally to the Internet and/or is related 
subnetworks and subcomponents. 

[0033] As one skilled in the art will appreciate, the present invention may be embodied 

as, among other things: a method, system or combination of systems, or a computer-program 
product. Accordingly, the present invention may take the form of a hardware embodiment, a 
software embodiment, or an embodiment combining software and hardware. In a preferred 
embodiment, the present invention takes the form of a computer-program product that includes 
computer-useable instructions embodied on one or more computer-readable media. 
[0034] Computer-readable media include both volatile and nonvolatile media, removable 

and nonremovable media, and contemplates media readable by a database, a switch, and various 
other network devices. Network switches, routers, and related components are conventional in 
nature, as are means of communicating with the same. By way of example, and not limitation, 
computer-readable media comprise computer-storage media and communications media. 
[0035] Computer-storage media, or machine-readable media, include media implemented 

in any method or technology for storing information. Examples of stored information include 
computer-useable instructions, data structures, program modules, and other data representations. 
Computer-storage media include, but are not limited to RAM, ROM, EEPROM, flash memory or 
other memory technology, CD-ROM, digital versatile discs (DVD), holographic media or other 
optical disc storage, magnetic cassettes, magnetic tape, magnetic disk storage, and other 
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magnetic storage devices. These memory components can store data momentarily, temporarily, 
or permanently. 

[0036] Communications media typically store computer-useable instructions - including 

data structures and program modules - in a modulated data signal. The term "modulated data 
signal" refers to a propagated signal that has one or more of its characteristics set or changed to 
encode information in the signal. An exemplary modulated data signal includes a carrier wave or 
other transport mechanism. Communications media include any information-delivery media. By 
way of example but not limitation, communications media include wired media, such as a wired 
network or direct-wired connection, and wireless media such as acoustic, infrared, radio, 
microwave, spread-spectrum, and other wireless media technologies. Combinations of the above 
are included within the scope of computer-readable media. 

[0037] The components used to accomplish the repeat build process of the present 

invention are shown in FIG. 1. Referring to the figure, we see that the system comprises a first 
computing device 10, a second computing device 12, and an external version storage system 14. 
[0038] First computing device 10 may be any sort of computing device capable of 

supporting version controlling software thereon. For example, device 10 might be a personal 
computer. It also might be included in a network of personal computers. In the embodiment 
shown in FIG. 1, a standard NT workstation is used which operates on an SMB protocol. It will 
be apparent to one skilled in the art, however, that numerous kinds of computing devices could 
be used and still fall within the scope of this invention. It may also be seen that first computing 
device 10 includes numerous components. 

[0039] One of these components is a scheduler 16. Scheduler 16 is a computer program 

designed to perform scheduling functions, such as the initiation or termination of jobs. In the 
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embodiment shown in FIG. 1, an NT scheduler has been used. Other types of scheduling 
programs or other techniques will be known to those skilled in the art and would also fall within 
the scope of the invention here. 

[0040] Scheduler 16 is used to initiate batch files 18 at a specified time, or on a 

predetermined schedule. The batch files 18 will be activated to accomplish a build on the second 
computing device 12. Batch files are files that contain a series of commands which are to be 
processed in sequence. Here, the batch files 18 are used to initiate builds of an application on 
second computing device 12. These batch files 18 are initiated by scheduler 16. Scheduler 16 
may be set to cause the execution of the batch files upon the expiration of a particular amount of 
time - at a particular interval. In the present embodiment, scheduler 16 initiates these builds 
nightly. Because of the repeat nature of these builds, they will hereinafter also occasionally be 
referred to as rebuilds. Other intervals could of course be used. Additionally, it may also be 
desirable to initiate builds on demand at no particular predetermined time. Accomplishing 
execution at any particular interval or on demand may all be done in a manner that is well known 
to those skilled in the art and thus, the invention is not to be considered limited to any particular 
build-initiation methodology. 

[0041] Information regarding builds which have been initiated and completed may be 

communicated to a project manager, or other entity, by way of email or other means by way of a 
build reporter 38. There are many ways which will be known to those skilled in the art of 
reporting information regarding builds from the batch files 18. The technique employed here is 
to use a simple java-con trolled SMTP client to send an e-mail. These emails will enable 
information regarding builds to be made available to any interested individual, e.g., a project 
manager. 
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[0042] Also included in first computing device 10 is an internal version control server 20. 

Internal version control server 20 is simply a form of version controlling software that is 
installed on device 10. Version control software applications are also often referred to as source 
control tools. The particular version control program used here is widely used and known as 
"CVS." 

[0043] CVS is used to record the history of source files. Sometimes bugs enter into 

source code when a program is modified in development. Significant time, however, might 
elapse between when the bug-infested modification is made and when the bug is actually 
discovered. With CVS, the user is able to go back in time and determine which version of the 
code created the bug. This can assist the programmers in many ways. Especially when a group 
of programmers are working together simultaneously in developing or testing the same 
application. It is easy for one programmer to overwrite the changes made by another. CVS 
solves this problem by insulating different developers. Each developer works from a different 
device 10 into a different directory from one another. CVS then merges the work when each 
developer is done. 

[0044] The components of some version control systems are completely internal to first 

computing device 10. Such arrangements, in which a repository is maintained on the same, or 
another personal computer, could also be used with the present invention. In the FIG. 1 
embodiment, however, uses the more common arrangement wherein an external version control 
storage system 14 includes an external version control server 34 and a cooperating repository 36. 
In such an arrangement, numerous first computing devices (work stations) , my utilize the same 
storage system 14 for version-control purposes. In such an arrangement, server 34 receives or 
sends files from an internal version control server 20. With each new version that is checked in 
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to the version control repository 36, a tag is assigned which will later enable a user to identify a 
particular version of an application. Server 34 stores new versions of applications in repository 
36 along with the assigned tag. Versions may also be withdrawn from repository 36 by first 
computing device 10 by referencing the tag. All of this is known technology. Reference may be 
made to Version Management With CVS by Cederqvist et al. (2003) for more information on 
CVS systems and how they operate. 

[0045] One aspect of the present invention is that additional files are checked into along 

with a properly functioning version of the application which is to be built on the second 
computing device. In the preferred embodiment, the version of the application will comprise two 
XML files and a number of XSL files. More specifically, the application will include: (i) a first 
XML file including environmental configuration generating scripts designed to run in at least 
one process on the second computing device, (ii) a second XML file including the objects of the 
application which makes reference to the environmental XML file, and (iii) a number of XSL 
files. A block diagram showing these features is disclosed in FIG 3. 

[0046] All of these files are checked into the version control system's repository 36 with 

an appropriate tag for identification purposes. The tag will later be used to call up this particular 
version of the application. 

[0047] The nature of XML files in general will be well known to those skilled in the art. 

Such files are designed to deliver information over the Web or some other protocol. They do not 
comprise a computer language per se, rather, they include a way of defining languages that are 
developed along its general principles. The XML files of FIG. 3 fall within these general 
characteristics. 
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[0048] With respect to the two kinds of XML files used here, object-XML file 204 

includes information on what a group of executables need in order to run - not the specifics 
regarding the environmental parameters. Though object-XML file 204 contains no 
environmentally-specific parameters, it does make reference to the environmental XML file 
(which contains these parameters) in order to make the application work. One embodiment of 
such an object-XML file is disclosed at the end of this specification before the claims. 
[0049] Environmental-XML file 202 contains the environmental-specific configurations 

of the application. As may be seen in FIG. 4, the environmental-XML file 202 includes: (i) an 
environmental-control label 208; (ii) a group of global environmental parameters 210 that are 
specific to the environment, but not specific to that particular application; (iii) a group of 
application parameters 212 that are specific to that particular environment; and (iv) a number of 
server-class-specific parameters 214 which, when edited allow configuration-changes specific to 
particular server classes. One embodiment of such an environmental-XML file is disclosed at 
the end of this specification before the claims. 

[0050] The information in the object-XML file 204 and environmental-XML 202 file 

enables adaptation to a particular environment having particular parameters dynamically. 
Because of this, new configurations need not be developed every time the application is built on 
the second computing device. The environmental-XML file 202 is available to whomever is 
running the environment. Using it, a programmer sets the environmentally-specific parameters 
210 to do whatever is desired and needed for that specific environment. This automates the 
rebuild process, because gives the user great flexibility because they will not have to reconfigure 
the environmental parameters to rebuild the application. 
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[0051] Additionally, configuration generating scripts in the environmental XML file are 

used to allow the user to create an environment in the second computing device. Scripts are 
essentially a series of pre-programmed steps including preconceived answers to sequences of 
anticipated prompts. 

[0052] These scripts work through a command interface, e.g. Pathcom™ (not shown), 

that is provided into a control process in the second computing device in order to allow the 
creation of or changes in environmental parameters. More will be described of this later. 
[0053] The XSL files 206 contain a language which is used to transform XML-based 

data into HTML or other presentation formats, for display in a web browser. The transformation 
of XML into formats, such as HTML, is done in a declarative way, making it easier and more 
accessible. XSL uses XML as its syntax, freeing XML authors from having to learn another 
markup language. Here, as is common place, the XSL files contain a series of commands that 
are basic generic utilities. These commands will typically not change from application to 
application and will typically be included with every XML-based application. 
[0054] Turning now back to the remaining components of first computing device 10, we 

can see in FIG. 1, the device includes a proxy server 28. Proxy server 28 is a software 
application that enables device 10 to send and receive messages over the Internet. It is used in 
the FIG. 1 arrangement to accomplish command communications between devices 10 and 12 
though a peer-to-peer connection 32. In the preferred embodiment, this is a TCP/IP 
(Transmission Control Protocol/Internet Protocol) connection 32. These build-related 
communications are used to accomplish a build on the second computing device 12 in a manner 
that will be explained hereinafter. 
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[0055] Second computing device 12 could be the same or a different type of computing 

device from first computing device 10. In the embodiment disclosed in FIG. 1, however, the 
second computing device is a larger-type of computer. Even more specifically, device 12 is a 
Tandem™, the software and hardware for which are available from Hewlett-Packard, Inc. The 
operating system of the Tandem™, in this embodiment, is run on OSS. The Tandem™, 
however, could be operated on Gaurdian™ or some other type-system. Other kinds of 
computing devices and different kinds of operating systems could, of course, be used to 
comprise second computing device 12 and would still fall within the scope of the present 
invention. For example, other computers operated on Unix or Windows™ or other systems 
could be used as well in manners that fall well within the scope of the present invention. 
[0056] Turning now to the specifics regarding the components of second computing 

device 12, we see it includes therein a masquerading drive 22. Masquerading drive 22 is a 
process that, when installed causes second computing device 12 to appear as a drive on first 
computing device 10. As one part of the present invention, devices 10 and 12 may work on 
operating systems that communicate using different types of protocols. For example, in the FIG. 
1 embodiment of the present invention, the operating system for first computing device 10 
speaks the SMB (Server Message Block) protocol. Also in the FIG. 1 embodiment, second 
computing device 12 may operate on some based on Unix or OSS. Masquerading drive 22 
enables second computing device 12 to be accessed for building purposes as if it were included 
on the network of first computing devices 10. Thus, source code by be developed on second 
device 12 from first device 10. 

[0057] In the embodiment shown in FIG. 1, the masquerading drive 22 is a Samba™ 

drive. Samba™ is a well known product readily available off the shelf which is able to enable 
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bring a Unix or Unix-like machines onto an SMB-based network. Here it is used to give file 
access to the second computing device 12. Other arrangements, of course, might work equally as 
will and would fall within the scope of the present invention. 

[0058] Masquerading drive 22 enables the build to be made into build directory 24. 

Directory 24 is the directory into which the objects are to be deployed in the second computing 
device. 

[0059] These objects are built into directory 24 using a maker 26. Maker 26 is a software 

tool that is used to generate executables and other non-source files of a program from the 
program's source files, which are transmitted to the second computing device 12 from version 
control server 20 of first computing device 10. Maker 26 gets its knowledge of how to build the 
program from a special file which lists each of the non-source files and contains information on 
how to compute it from other files. In the FIG. 1 embodiment of the present invention, maker 26 
is a commercially available program called "GNU Make," also known as "gmake" or "Make." 
The special file referred to above is called a "makefile" when GNU Make is used. GNU Make is 
well known in the art. And one familiar with GNU Make is familiar with how it may be used 
within an arrangement like that shown in FIG. 1 to build an application into a directory like 
directory 24. 

[0060] Second computing device 12 receives and sends build information from and to 

first computing device 10 from maker 26 using a command message station 30. In the FIG. 1 
embodiment, command message station 30 is a command hublet. A command hublet is able to 
be run on a Tandem™ computing device. It is a software application that is able to receive the 
messages from the first computing device telling the maker 26 to start the building of the 
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application. It also returns information regarding the build to the first computing device via the 
TCP/IP connection 32. 

[0061] Though a TCP/IP connection 32 is used in the FIG. 1 embodiment, other means 

supporting peer-to-peer or other networking means for allowing connectivity functions known to 
those skilled in the art could be used as well. 

[0062] Now that the various components of the embodiment disclosed in FIG. 1 have 

been described, we may discuss how all of these components work together to kick off a build on 
the second computing device 12 using the first computing device 10. To start, scheduler 16 is 
typically set to trigger the batch files 18 at a predetermined time to initiate a build. Sometimes at 
regular intervals. In one embodiment, the builds occur nightly. In other embodiments, no 
scheduler would be used and the batch processes 18 would be kicked off at only one specific 
time, or manually by other means known to those skilled in the art. Regardless, once the batch 
files 18 are initiated - either by the scheduler or manually - the build begins. 
[0063] In the build process, the batch files 18 contain a series of commands which are 

processed in sequence to cause internal version control server 20 to recall a particular version of 
the application using a tag. Scripts have been written that execute on the platform of the first 
computing device 10 which allow it to get the latest, or other desired version, of code out of the 
version control system. In the embodiment disclosed in FIG. 1, the internal version control 
server 20 uses the tag to draw the desired version of the application from the repository 36 in the 
external version control system 14 using server 34 in a manner known to those skilled in the art. 
[0064] In one embodiment Once the application, comprising the XML environmental, 

XML object, and XSL files have been retrieved from the version control system, they are given 
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file access to, and then deployed into directory 24 on the second computing device using 
masquerading drive 22. 

[0065] The commands necessary for deployment are directed to the second computing 

device from the first computing device through a line of communications comprising proxy 
server 28, TCP/IP connection 32, and command message station 30. This line of 
communications is used by the process as follows. 

[0066] First, the initiating commands originate from the processing batch files 18. Next, 

they are transmitted, via TCP/IP connection 32, to the command message station 30 in second 
computing device 12. 

[0067] Once the commands to kick off the build are received in station 30 in the second 

computing device, command message station 30 gives maker 26 the instructions necessary to 
begin the build within directory 24. 

[0068] At this point, the configuration generating scripts in environmental-XML file 202 

generate the configurations necessary to build the application into a particular environment on 
the second computing device 12. 

[0069] FIG. 2 shows the processes which may exist on a typical second computing 

device. In this figure, two different environments, E A and E B . An environment is a set of 
servers, server classes, TCP's, terminals, and messaging systems that operate under one 
controlling process. Though only two environments are shown in FIG. 2, the second computing 
device should not be considered as limited to having only two environments operating therein. 
The figure has been adapted as such for simplicity. Most second computing devices would have 
numerous environments running simultaneously. One example of an environment used on a 
Tandem, e.g., is what is referred to as a PATHMON environment, which will be known to one 
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skilled in the art, and is the kind of environment shown in the FIG. 2 embodiment. Other similar 
processes, however, exist which would fall within the scope of the present invention. 
[0070] The operation of second computing device 12 is dependent on the support of 

multiple servers. A "server" as used here, means simply a process that receives, and may also 
send, messages. Servers are used, practically speaking, to provide operations for requestors by 
reciprocal messaging. Environment E A has two server classes, SC AJ and SC A 2. Each of these 
server classes SC A i and SC^ include three servers, Si, S2, and S 3 . Each server is one process of 
a particular application. Each server class may include numerous servers, each of these servers 
running the same executable of an application at the same time. Accordingly, each of servers Si, 
S2, and S3 falling within the same server classes will run the same executable. These identical 
Si, S 2 , and S3 executables are all running simultaneously, but in response to different requests. 
[0071] Each of the servers created within a particular server class are configured through 

a controller. With respect to FIG. 2's environment E A , a controller 130 is shown. It may also be 
seen that controller 130 operates though a communications process 132. Communications 
process 132 may be any communications protocol, i.e., the internet. Controller 130 is a process 
in environment E A that (i) maintains configuration-related information, (ii) grants links to server 
classes in response to requests; and (iii) performs all process control (e.g., starting, monitoring, 
restarting, and stopping) of server processes and TCP's. It is in essence, what makes the 
environment exist, and function. 

[0072] A controller operates with respect to the server classes as a process/server 

messaging manager. It allows you a clean slate that allows you to set up whatever environmental 
parameters are important to the application. 
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[0073] It is also a load balancing tool. When a message comes in through a user 

interface, it picks the particular instance of the server - the particular process - to talk to based 
on how busy the different processes (servers) are. Because, e.g., all of the servers Si, S2, and S3 
in server class SC A i are capable of running the same executable, the controller looks for the 
running process/server that is not currently sending or receiving a message for use. If no 
processes are running on a particular server, the controller will start a process up in order to 
fulfill the request. It may be seen that all the server classes shown in FIGs. 2, 5, and 6 include 
three servers each. This number is only illustrative in nature. It is well known that a server class 
may contain as many or few server classes as is desired for a particular objective. Here, three 
has been chosen as a manageable number only and is not intended to be in any way limiting. 
[0074] One example of a controller which may be used in the second computing device is 

what is known commercially as the Pathmon™ process, or a "pathway." Pathmon™ is software 
application that is run on a Tandem™ (a large computer). Both the software and computer are 
manufactured by Hewlett-Packard, Inc. 

[0075] In the embodiment of the invention disclosed in FIG. 2, controller 130 is this 

Pathmon™ process. As can be seen in FIG. 2, controller 130 is used to control server classes 
SC A i and SCa2 through communications controller 132. 

[0076] Environment E B is structured essentially the same as is environment E A . Like 

environment E A , environment E B has three servers, S B! , S B2 , and S B3 . Each of these servers are 
shown within a server class SC B . Like server class SC A , server class SC B is created through and 
managed by controller 134. Controller 134, like controller 130, is a process in environment E B 
that maintains configurations, links server classes, and controls all server processes in 
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environment E B . Controller 134 accesses server class E B through a communications controller 
136. 

[0077] Though the E B environmental arrangement is identical to the environment E A 

arrangement, the two environments would typically be subject to different parameters requiring 
different configurations. Here, environment E A and E B are test environments. Alternatively, 
however, environment E A may be a test environment whereas environment E B is adapted and 
used for development. Yet a third environment (not shown) might be devoted to production. 
There may also be multiple test, development, and/or production environments for the same 
application on the second computing device - all requiring different parameters (e.g., web 
servers, directory pathways). The actual type of environment or number of environments are not 
a limitation on the processes of the present invention. It is significant, however, to note that each 
environment has different environmental parameters that must be met. Primarily what is meant 
by the phrase "different environment" is that the application is subject to a different set of data 
tables. However, there are other types of environmental parameters, such as the directories, 
server classes, and/or websites that are to be referenced. 

[0078] The reasons for creating different environments for the same application are 

numerous. One example of why this is done is so that concurrent development of the same 
application may be done in multiple regions. For example, oftentimes an application that is 
being developed becomes excessively complicated. One group of programmers may decide to 
develop or test a portion, or branch, of the application. A second group of developers may be 
simultaneously working on another branch of the application. To enable concurrent testing by 
the two different groups of programmers, different environments are set up for each group of 
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programmers so that they are able to work with concurrently running versions of the same 
application. 

[0079] Each of controllers 130 and 134, and thus environments Ea and Eb, are associated 

with a recognizable label, which is recognized by the controller in that environment. For 
example, controller 130 may respond to a label "$DV04." When $DV04 is referenced, it is 
recognized by controller 130, and it is known that the environment E A is being prompted. 
Controller 134 would have a different identifier, e.g., "$DV05." By referencing this different 
label, controller 134 will be prompted for controlling the processes in environment E B . This is 
how different environments can be accessed/created. 

[0080] Controller 130 of environment E A , and controller 134 of environment Eb may 

both be accessed from first computing device 10 through a user interface 140. Interfacing 
between first computing device 10 and second computing device 12 may be accomplished in any 
way known to those skilled in the art. In the FIG. 2 embodiment, however, first computing 
device 10 and second computing device 12 may have different system architectures and possibly 
even different operating systems. Under these circumstances, the user interface should be able to 
convert the code developed on the first computing device such that it can be recognized on the 
second computing device. In order to accomplish this, common interfaces through which object- 
oriented software on the first computing device can communicate with the processes on the 
second computing device, regardless of the possibly different platforms there between. Here, the 
interfacing is accomplished using what is known as Common Object Request Broker 
Architecture, or "CORBA." Using CORBA, application components on the first computing 
device can communicate with application components on the second computing device - 
regardless of the differences between the two systems. 
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[0081] The details of how the three groups of files shown in FIG. 3: (i) the object-XML 

file 204 which include the objects of the application; (ii) the environmentally-specific XML file 
202 which includes the environmental configuration generating scripts designed to run on second 
computing device 12; and (iii) the XSL files 206 are used in accomplishing the present invention 
will now be discussed. 

[0082] Object file 204 include information on what a group of executables need in order 

to run. 

[0083] In many ways, the XML object 204 and XML environmental 202 files work 

together. Object file 204 may reference environmental file 202 to obtain the environmental 
parameters it needs to work in a particular environment. It does not, however, contain things that 
are tied to a particular environment. It only configures the things that are not environmentally 
specific. It references only items that it needs which are common to all the server classes - not 
things specific to particular server classes. Thus, object file 204 will not have to be changed 
when you go from environment to environment. 

[0084] Environmental file 202 includes configurations for the particular environment and 

server classes into which the application is being deployed. Every server class has some 
parameters that are common to all of the other server classes. Other parameters will be different. 
These different environmentally-sensitive parameters are what will be maintained in 
environmental file 202. 

[0085] This separation of things environmentally specific versus those things that are 

non-environmentally-specific between the two XML files is what makes the application 
dynamically adaptable to different environments. Because of this, new configurations need not 
be developed every time the application is built on the second computing device. This file is 
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available to whomever is running the environment to be edited to set the parameters to do 
whatever is desired. This automates the rebuild process, because gives the user great flexibility 
because they will not have to reconfigure the environmental parameters to rebuild the 
application. Configuration generating scripts in the environmental XML file are used to allow 
the user to create an environment in the second computing device. 

[0086] Using these scripts, the user is able to automatically institute series of commands 

that would normally have to be manually entered. Its programmed answers to sequences of 
anticipated prompts generates the configuration-generating commands automatically so the user 
doesn't have to. 

[0087] These scripts work through a command interface, e.g. Pathcom™ (not shown), 

that is provided into a control process in the second computing device in order to allow the 
creation of, or changes in environmental parameters. The scripts in the environmental-XML file 
are encoded to do this. 

[0088] It will now be discussed in detail how these configuration generating scripts in 

environmental file 202 are used to accomplish a process of the present invention. 
[0089] First, the scripts issue a first command through the command interface, e.g. 

Pathcom™, which stops all the server classes running in the particular environment into which 
the application is desired to be disposed. This command is received through communication 
process 132 and given to controller 130. Controller 130 then stops all the server classes. 
[0090] Next, the scripts issue a second command which it removes all of the existing 

server class definitions from the environment. This command, like the first, travels through 
communications processor 132 where it is received by controller 130. Controller 130 then 
executes the removal of all of the server class definitions. This effectively deletes the server 
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classes, as may be seen in FIG. 5, from the environment. FIG. 5 shows server class SC A being 
deleted in this process. Though not pictured herein, any other server classes in environment E A 
would also be deleted by this process. 

[0091] The scripts then transmit a third command which adds the new server class 

definitions. These definitions are contained in environmental configuration file 202, and are 
used to configure the new server classes. The construction of two new server classes - SC A i new 
and SCa2 new may be seen in FIG. 6, each including newly created servers Si new, S2 new, and S3 

NEW- 

[0092] Finally, a fourth command is issued from the scripts that starts the new server 

classes and servers therein to thus start the application. 

[0093] By this process, the environment is merged with the new objects to create a series 

of server class configurations that define the behavior of the application. 

[0094] Once the build is complete, an output file may be transmitted back to the first 

computing device via the command line of communications. Maker 26 issues this file back 
through the command message station 30, over TCP/IP socket 32 to be received by proxy server 
,* 28. Once received and maintained in proxy server 28, this file will be drawn out by batch 
commands issued by the batch process 18, and communicated to the project manager, or other 
user by way of email using build reporter 38. The file is then saved by the build manager. 
[0095] As can be seen, the present invention and its equivalents are well-adapted to 

provide a new and useful method of creating a build from a first computing device having a 
version control system therein, onto a second computing device. Many different arrangements of 
the various components depicted, as well as components not shown, are possible without 
departing from the spirit and scope of the present invention. 
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[0096] The present invention has been described in relation to particular embodiments, 

which are intended in all respects to be illustrative rather than restrictive. Alternative 
embodiments will become apparent to those skilled in the art that do not depart from its scope. 
Many alternative embodiments exist but are not included because of the nature of this invention. 
A skilled programmer may develop alternative means of implementing the aforementioned 
improvements without departing from the scope of the present invention. 

[0097] It will be understood that certain features and subcombinations are of utility and 

may be employed without reference to other features and subcombinations and are contemplated 
within the scope of the claims. Not all steps listed in the various figures need be carried out in 
the specific order described. 

[0098] Set forth below are embodiments of the object and environmental XML files as 

discussed above. 
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OBJECT-XML FILE 



<?xml version= M l . 0" encoding="UTF-8 l! standalone= "no" 



< i - 



File Name: nanpObjectConf ig.xml --> 

- - > 

Description: - -> 

- - > 

MOD LOG --> 
__*★*★★★★*★********★★★*★★**★★*★**★★★★★★*★★★ --> 

Date CM# Done by Reason --> 

--========================================= - - > 

09/24/03 894 DBO Initial version --> 
__★★*★★★***★*★★★★★★*****★★★★***★★★★★★★★**** --> 

DOCTYPE System SYSTEM "ob j ectConf ig . dtd" > 



<System Name= "Unif iedRouting" > 

<!-- This section contains sets of environmental --> 
<!-- parameters that are used together --> 

<EnvSet Name="CommRetrySet"> 

< Env Name = 11 RETRY_PATHWAY " >< Re f e r enc e 
Re f = " CommPa t hway " / >< / Env > 

<Env Name= " RETRY_SERVERCLASS " ><Ref erence 
Ref = "RCOlServerClass " /></Env> 
</EnvSet> 

<EnvSet Name= "CorbaSet " > 

<Env Name= "GET_NS " >FALSE</Env> 
<Env Name="HTTP_DELAY">5</Env> 
<Env Name= "LOCAL_NS " >FALSE</Env> 
<Env 

Name="NSDOM_CFG_DBM">$SYSTEM. ZORBB10 .NSDCFGDB</Env> 

<Env Name ="PNS_URL">< Ref erence 
Ref ="NSLocation"/x/Env> 

<Env Name=" PUTINS ">FALSE</Env> 

< Env Name = " TCP I P_PROCES S_NAME " >< Re f e r enc e 
Ref ="TCPIPProcess"/x/Env> 

<Env Name="USE_NS">TRUE</Env> 

<Env Name="USE_PNS">TRUE</Env> 
</EnvSet> 



<EnvSet Name= " Error loggerSet " > 

< Env Name = " EMS_LOGLEVEL " > I NFO< / Env > 



1349881vl 



28 



<Env Name= l! EMS_TARGET"><Ref erence 
Ref = " EmsTarget 11 / >< /Env> 

<Env Name= M LOGID" ><Ref erence 
Ref ="ServerClassName 11 /></Env> 

<Env Name="PROCESS_NAME 11 xRef erence 
Ref = 11 ServerClassName " / >< /Env> 

<Env Name= " STD_LOGLEVEL 11 >INFO</Env> 
</EnvSet> 

<EnvSet Name= " RCO lSet " > 

< Env Name = " RC 0 1_PATHWAY " >< Re f e r enc e 
Re f = 11 CommPa t hway 11 / >< / Env > 

< Env Name = 11 RC 0 1_S ERVERCLAS S " >< Re f e r enc e 
Ref = ,, RC01ServerClass' , /x/Env> 
</EnvSet> 

<EnvSet Name="RetrySet 11 > 

<Env Name="MAX__RETRIES ,! >3</Env> 

<Env Name= I! RETRY__INTERVAL" >4</Env> 
</EnvSet> 

<EnvSet Name= n ServiceTypeSet ,! > 

< Env Name = " S ERVI CE_T YPE 11 >NNP< / Env> 
</EnvSet> 

<EnvSet Name="TD01Set " > 

< Env Name = " TD 0 1_PATHWAY 11 >< Re f e r enc e 
Ref = 11 CommPa t hway " / >< / Env> 

<Env Name= " TDO 1_S ERVERCLAS S " >< Ref erence 
Ref = If TD01ServerClass"/x/Env> 
</EnvSet> 

<EnvSet Name="TranIdServerSet "> 

<Env Name= ,, EXT_SYSTEM ,, >NADP</Env> 
< Env Name= " S YSTEM_TYPE " >RMS < / Env > 
< Env Name = " TRAN I D_PATHMONAME " > $ GLB L < / Env > 
<Env Name= "TRANIDJSERVERCLASSNAME » >G0S13 - 
RGTID00</Env> 

</EnvSet> 

<!-- This section contains the configuration params--> 
<!-- for each object. --> 

<Object Name= n NDP-AP n > 

<Define Name="_SRL_01 l! xMap 
Fi le= » \SDPLAB . $SYSTEM . Z0RBB1 0 . NSDSRL " / >< /Def ine> 
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< Env Name = " ERRORLOG " >< Re f e r enc e 
Ref = 11 ServerClassName 11 / >< /Env> 

<Env Name="MAX_DAYS_OLD">l</Env> 
<Env Name= "MAX_RETRY" >3</Env> 
<Env Name= " RETRY_INTERVAL " >4 < / Env> 
<Env Name= n SERVICE_TYPE n >NDP</Env> 
< Env Name = "S TART_T I ME_HHMM !, >1145</Env> 
<Env Name =" TRANS ACT I ONS_PER_TMF " >50</Env> 
< IncludeEnvSet SetName= " Error loggerSet " / > 
</Object> 

<Object Name= "NDP-CLLI -UPDATE " TMF= "ON" > 

<Def ine Name="TCPIP A PROCESS A NAME" xMap 
File="\SDPLAB.$ZB02A"/x/Def ine> 

<Define Name="_SRL_01"xMap 
File= " \SDPLAB . $SYSTEM. ZORBB10 .NSDSRL"/ ></Def ine> 

<Env Name=" ERRORLOG" ><Ref erence 
Ref = " ServerClas sName 11 / x /Env> 

<Env Name= " HIDECLLIDETAIL " >0N< /Env> 

<Env Name =" MAX_TMFS" >1</ Env > 

<Env Name="POOL_OWNER">l</Env> 

<Env Name="RESPONDER_SERVICE">REHOME_UPDATE</Env> 
<Env Name= " TRUNKI NG_REPORTJDTD" xRef erence 
Ref ="WebLocation"/>/dtd/TrunkingReport .dtd</Env> 
< Env Name = " TRUNKI NG_JREPORT_I D " > 5 < / Env > 

< Env Name = " TRUNKI NG_RE PORT_I F 11 x Re f e r enc e 
Ref = "NSPath" / >/Report I f < / Env> 

< IncludeEnvSet SetName= " CorbaSet " / > 

< IncludeEnvSet SetName= " Error loggerSet " / > 
< IncludeEnvSet SetName= " TranldServerSet " / > 

</Object> 

<Object Name= "NDP-COMM-MGR" > 

< Argument s xOrbProf i 1 e / x /Argument s > 
<Define Name="TCPIP^PROCESS A NAME" xMap 

Fi le= " \SDPLAB . $ZB02A" /x/Def ine> 
<Define Name="_SRL_01" xMap 

File="\SDPLAB. $SYSTEM.ZORBB10. NSDSRL"/ x/Def ine> 

< Env Name = " D I S PLAY_DUMP " > t rue < / Env > 
< Env Name = " ERRORLOG "x Reference 

Ref =" ServerClassName "/></Env> 

<Env Name="EXT_SYSTEM" >NADP</Env> 

<Env Name="MAX_RETRIES">3</Env> 

< Env Name = " NDP_S WCOMMI F " x Re f e r ence 
Re f = " NS Pat h " / > / SwComml f < / Env> 

<Env Name= " RETRY_INTERVAL " > 1 0 < /Env> 

<Env Name= l! SERVICE_TYPE">NNP</Env> 
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<Env Name= " SYSTEM_TYPE " >RMS< /Env> 
<Env Name= 11 TD01_PATHMONAME" ><Ref erence 

Re f = 11 CommPa t hway 11 / >< / Env > 

<Env Name="TD01_SERVERCLASSNAME ,, xRef erence 

Ref =" TD01ServerClass"/x/Env> 

<Env Name="TIMEOUT">1000</Env> 

< IncludeEnvSet SetName= " CorbaSe t " / > 

< IncludeEnvSet SetName= 11 ErrorloggerSet " / > 

<SCRef PathmonEnv= " ARCHIVE_PURGER_PATHMONAME " 

SCEnv= "ARCHIVE_JPURGER_SERVERCLASSNAME" SCOb j = "NDP- 

AP n /> 

<SCRef PathmonEnv= " DMO_RES PONDER_PATHMONAME " 
SCEnv= "DMO_RESPONDER_SERVERCLASSNAME " SCObj = "NDP- 
DMORSPNDR " / > 

<SCRef PathmonEnv= 11 RESPONDER_PATHMONAME " 
SCEnv= "RESPONDER_SERVERCLASSNAME " SCObj = ,, NDP-RSPNDR ,l /> 

<SCRef PathmonEnv= 11 SCHEDULER_PATHMONAME " 
SCEnv= » SCHEDULER'S ERVERCLASSNAME 11 SCObj = " SCHEDULER" / > 

< SCRef PathmonEnv= " STATUS_BROKER_PATHMONAME " 
SCEnv= ,! STATUS_BROKER_SERVERCLASSNAME n SCObj = ,! STATUS - 
BROKER" /> 
</Object> 

<Object Name = "NDP- CORE "> 

<Define Name="_SRL_01 " xMap 
File="\SDPLAB. $SYSTEM. ZORBB10 . NSDSRL" /x/Def ine> 

<Env Name= " ERRORLOG" xRef erence 
Ref = " Server CI as sName " / ></Env> 

<Env Name="MAX_RETRIES">3</Env> 

<Env Name ="RC01_NAME">< Ref erence 
Ref =" RC01ServerClass n /x/Env> 

<Env Name= " RCO 1_PATHWAY_NAME 11 x Ref erence 
Re f = " CommPa t hway 11 / >< / Env > 

<Env Name= " RETRY_INTERVAL " > 1 0 < /Env> 

<Env Name="SERVICE_TYPE">NDP</Env> 

<Env Name="TD01_NAME" xRef erence 
Ref ="TD01ServerClass M /x/Env> 

<Env Name= " TD01_PATHWAY_NAME" xRef erence 
Re f =" CommPa t hway "/ >< / Env> 

< Env Name = « T I MEOUT_VALUE " > 0 < / Env > 

<Env Name= " TRANSACTION_APPROVAL_FLAG " >N< /Env> 

< IncludeEnvSet SetName= " ErrorloggerSet "/> . 

<SCRef PathmonEnv= "RESPONDER_PATHWAY_NAME " 
SCEnv= "RESPONDER_NAME " SCObj = "NDP-RSPNDR " /> 

<SCRef PathmonEnv= " SCHEDULER_PATHWAY_NAME » 
SCEnv= " SCHEDULER_NAME " SCObj = " SCHEDULER" / > 
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<SCRef PathmonEnv= " STATUS_BROKER_PATHWAY JSTAME " 
SCEnv= " STATUS_BROKER_NAME " SCOb j = " STATUS - BROKER " / > 

<SCRef PathmonEnv= 11 UCG_PATHWAY_NAME " 
SCEnv= "UCG_NAME " SCOb j = "UCG-DMS2 50 11 / > 
</Object> 

<Object Name= "NDP-DMORSPNDR" > 

< Argument s><OrbProfile/>< /Argument s > 
<Def ine Name= "TCPIP^PROCESS^NAME" xMap 

File= " \SDPLAB . $ZB02A" /x/Def ine> 
<Define Name="__SRL_01"xMap 

File="\SDPLAB . $SYSTEM. ZORBB10 . NSDSRL" / x/Def ine > 
<Env Name= " ERRORLOG " xRef erence 

Ref = " ServerClassName " / x /Env> 

<Env Name= 11 RETRY_PATHMON__NAME " xRef erence 

Re f = " CommPa t hway " / x / Env > 

<Env Name="RETRY_SERVERCLASS_NAME" xRef erence 

Ref = "RetryServerClass " / x/Env> 

<Env Name="SERVICE_TYPE">NDP</Env> . 

<Env Name= " SERVLINK_INDEX " > 5 0 0 < /Env> 

<Env Name= " TRANID_TASK_ID " >2 5 < /Env> 

< IncludeEnvSet SetName= " CorbaSet " / > 

< IncludeEnvSet SetName= " Er rorloggerSet " / > 

< IncludeEnvSet SetName= " Ret rySe t " / > 

< IncludeEnvSet SetName= " TranldServerSet 11 / > 

<SCRef PathmonEnv= " RESPONDER_PATHWAY__NAME 11 

SCEnv= » RES PONDER__NAME » SCOb j = !I NDP-RSPNDR 11 / > 
</0bject> 

<0bject Name = " ND P - POOL - MGR 11 > 
<Define Name="_SRL_01 n xMap 
File="\SDPLAB.$SYSTEM.ZORBB10. NSDSRL" /x/Def ine> 
<Env Name =" OWNER__CODE " >1< /Env > 
< IncludeEnvSet SetName= " ErrorloggerSet 11 / > 

</Object> 

<Object Name= "NDP-QUERY" > 

<Argument s xOrbPro f i 1 e / x /Argument s > 

<Def ine Name =" TCP I P A PROCESS X NAME " xMap 
File=" \SDPLAB. $ZB02A ,! / x/Def ine> 

<Define Name= l! _SRL_01 n xMap 
File=" \SDPLAB. $SYSTEM. ZORBB10. NSDSRL" / x/Def ine > 

<Env Name= "CLLIROUTELISTQUERYIF" xRef erence 
Ref ="NSPath"/>/ClliRouteListQueryIf</Env> 

< Env Name = " D I AL PLANQUER Y IF"xReference 
Ref ="NSPath"/>/DialPlanQueryIf </Env> 

<Env Name="EMS_LOGLEVEL">DISABLED</Env> 
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< Env Name = " EMS_TARGET " >< Re f e r ence 
Ref = " EmsTarget " / ></Env> 

< Env Name = " GENQUERY IF"xReference 
Re f = 11 NS Pat h "/ > / GenQuery I f < / Env> 

< Env Name = " JVRQUERY IF" xReference 
Ref= M NSPath"/>/JVRQueryIf </Env> 

<Env Name= "LOGID" xReference 
Re f = " S e rve r Cl a s sName " /></ Env > 

<Env Name= l! MAX__RETRIES " >2</Env> 

<Env Name= "NNP_SERV_TYPES " > "NNP , NDP " < /Env> 

<Env Name= n NPASPLITQUERYIF" xReference 
Ref = ,, NSPath ,, />/NPASplitQueryIf</Env> 

<Env Name= 11 PROCESSJSTAME 11 xReference 
Ref = M ServerClassName " /x/Env> 

<Env Name= " REHOMEQUERYI F " xReference 
Re f = " NS Pa t h " / > / Re home Que ry I f < / Env > 

<Env Name= " RETRY_INTERVAL " >4 < /Env> 

<Env Name= f, STD_LOGLEVEL n >INFO</Env> 

<Env Name= n SWCOMMQUERYIF"xReference 
Re f = 11 NS Pa t h " / > / S wCommQue ry I f < / Env > 

< IncludeEnvSet SetName= " CorbaSet " / > 
</Object> 

<Object Name= " NDP -REC- BACK" > 

< Argument sxOrbProfile/x / Argument s > 
<De f ine Name = " TCP I P A PROCESS ^NAME " > <Map 

File= l, \SDPLAB.$ZB02A ,, /x/Def ine> 

<Define Name= ,! _SRL_01 l! xMap 
File= » \SDPLAB . $SYSTEM . Z0RBB1 0 . NSDSRL " / x /Def ine> 

<Env Name= " ANN_RTEREF_RANGE " >3 3 0 - 3 3 1< /Env> 

< Env Name = " CORE_TAS K_I D » > 3 0 < / Env > 
<Env Name= !, DTDFILE ,! xReference 

Ref = M WebLocation !, />/dtd/ReconReport .dtd</Env> 

<Env Name= "ERRORLOG" xReference 
Ref = " ServerClassName " / ></Env> 

<Env Name= "EXT_SYSTEM" >NADP</Env> 

<Env Name= n FILE_ID n >91</Env> 

<Env Name= "HIDECLLIDETAIL" >ON</Env> 

<Env Name= "MAX_TMFS " >1</Env> 

<Env Name= n POOL_OWNER n >l</Env> 

<Env Name="REPORT_PATH" xReference 
Ref = n DeployPath"/>/log</Env> 

<Env Name="RPT_MIN_PCT_INC ,, >5</Env> 

<Env Name= " SERVICE_TYPE" >NRC</Env> 

<Env Name= " SERVLINK_INDEX " > 5 0 0 < / Env> 

<Env Name= " SIX__DIGIT_RTEREF_RANGE ">lll-899 < /Env> 

<Env Name= "SYSTEM_TYPE" >RMS</Env> 
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< Env Name = " TEN_D I G I T_RTERE F_RANGE ">0-1023</Env> 
<Env Name= n TRANID_TASK_ID ,f >25</Env> 
<IncludeEnvSet SetName= " CorbaSet " / > 
<IncludeEnvSet SetName= " Error loggerSet "/> 
<IncludeEnvSet SetName="RetrySet "/> 
</Object> 

<Object Name = " NDP - REC - FRONT " > 

< Argument s><OrbProfile/>< /Argument s > 
<Def ine Name= ll TCPIP^PROCESS^NAME"xMap 

File="\SDPLAB.$ZB02A"/></Def ine> 
<Define Name= "_SRL_01 11 ><Map 

File= n \SDPLAB. $SYSTEM. ZORBB10.NSDSRL n /x/Def ine> 
<Env Name = n COMMAND_MACH INE" x Reference 

Ref = 11 ReconCommandMachine 11 / x /Env> 

< Env Name = " COMMAND_SUBVOL " >< Re f e r enc e 

Re f = ,! Re c onCommandS ub vo 1 11 / x / Env > 

< Env Name = " COMMAND_VOLUME 11 xRe f erence 

Re f = 11 Re c onCommandVo 1 ume " / x / Env > 

< Env Name = " ERRORLOG " x Reference 

Ref = l, ServerClassName ,, /x/Env> 

<Env Name="FILE_ID lf >9999</Env> 

<Env Name= l! RECONjSERVER_CONTEXT MI xRef erence 

Ref = "NSPath" / >/ReconServerIf </Env> 

<Env Name= " SERVICE_TYPE " >NRC< /Env> 
< Env Name= " SERVLINK_INDEX » > 5 0 0 < /Env> 
<Env Name= "TD01_NAME " xRef erence 

Ref ="TD01ServerClass M /x/Env> 

<Env Name= " TDO 1_PATHWAY_NAME " xRef erence 

Ref = "CommPathway"/x/Env> 

< Env Name = " TRANI D_TAS K__I D " > 2 5 < / Env > 
< Inc ludeEnvSet SetName= " CorbaSet 11 / > 
< IncludeEnvSet SetName= " Error loggerSet " / > 
<IncludeEnvSet SetName="RetrySet 11 /> 
<IncludeEnvSet SetName="TranIdServerSet " /> 
</Object> 

<Object Name = " ND P - RE PORT " > 

<Argument s xOrbProf i 1 e / x /Argument s > 
<Def ine Name= "TCPIP^PROCESS^NAME" xMap 

File= " \SDPLAB . $ZB02A"/ x/Def ine> 
<Define Name = M _SRL_01 "x Map 

File- » \SDPLAB . $SYSTEM . Z0RBB1 0 . NSDSRL " / x /Def ine> 
<Env Name= " EMS__LOGLEVEL n >DISABLED</Env> 
< Env Name = " EMS_TARGET "xReference 

Ref = 11 EmsTarget " / ></Env> 
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<Env Name= H LOGID" ><Ref erence 
Ref = " ServerClassName " / ></Env> 

<Env Name="MAX_RETRIES">2</Env> 

<Env Name="PROCESS_NAME"xRef erence 
Ref =" ServerClassName "/x/Env> 

<Env Name= "REPORT IF" ><Ref erence 
Re f = » NS Pa t h " / > /NANPRepor 1 1 f < / Env> 

<Env Name= 11 RETRY_INTERVAL 11 >4 < / Env> 

<Env Name= 11 STD_LOGLEVEL n >INFO</Env> 

< Inc ludeEnvSet SetName= " CorbaSet " / > 
</Object> 

<Object Name="NDP-REQUEST" > 

< Argument s><OrbProfile/>< /Argument s > 
<De f ine Name= " TCPI P A PROCESS ^NAME " xMap 

File = H \SDPLAB . $ZB02A n / x/Def ine> 
<Define Name="_SRL_01"xMap 

File= ,f \SDPLAB . $SYSTEM. ZORBB10 .NSDSRL"/ x/Def ine> 

< Env Name = " D I S PLAY_DUMP " > t rue < / Env > 

< Env Name = " ERRORLOG " x Re f e r enc e 
Ref = " ServerClassName " / x /Env> 

<Env Name= "MAX__RETRIES " >3</Env> 

< Env Name = H ND P_RS_CLL I ROUTEL I STIF !! xRefe r enc e 
Ref= n NSPath"/>/ClliRouteListIf</Env> 

<Env Name= "NDP_RS_DIALPLANIF" xRef erence 
Ref="NSPath"/>/DialPlanIf</Env> 

<Env Name= "NDP_RS_JVRIF" xRef erence 
Ref="NSPath"/>/JVRIf</Env> 

< Env Name = " NDP_RS JSTPAS PL I T I F 11 x Re f erence 
Ref ="NSPath n />/NPASplitIf</Env> 

< Env Name = " NDP_RS_REHOME I F " >< Re f e r ence 

Ref = n NSPath ,f />/RehomeIf </Env> 

<Env Name= " RETRY^I NTERVAL 11 > 1 0 < / Env> 
<Env Name= " S ERVI CE_TYPE " >NDP</Env> 
<Env Name= "TIMEOUT" >500</Env> 
<IncludeEnvSet SetName= "CorbaSet "/> 
<IncludeEnvSet SetName= " Error loggerSet " / > 
<IncludeEnvSet SetName="TranIdServerSet " /> 
<SCRef PathmonEnv= " ARCH I VE_PURGER_PATHMONAME " 

SCEnv= " ARCH I VE_PURGER_S ERVERCLAS SNAME " SCOb j = "NDP- 

AP"/> 

<SCRef PathmonEnv= " CORE_PATHMONAME " 
SCEnv="CORE_SERVERCLASSNAME" SCObj ="NDP-CORE"/> 

<SCRef PathmonEnv= " STATUS_BROKER_PATHMONAME " 
SCEnv= " STATUS_BROKER_SERVERCLASSNAME " SCObj = " STATUS - 
BROKER" /> 
</Object> 
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<Object Name= !, NDP-RSPNDR"> 

<Argument s xOrbProf i le/ >< /Argument s > 

<De f ine Name= 11 TCPI P^ PROCESS ^NAME " xMap 
File= " \SDPLAB . $ZB02A" / >< /Define > 

<Define Name= "_SRL_01 " xMap 
File="\SDPLAB. $ SYSTEM . ZORBB10 . NSDSRL" /x/Def ine> 

< Env Name = " ERRORLOG "xReference 
Ref = " ServerClas sNatne " / >< /Env> 

<Env Name="HTTP_DELAY">5</Env> 

<Env Name= "MAX_RETRIES " >2</Env> 

<Env 

Name="NSDOM_CFG_DBM">$ SYSTEM. ZORBB10 . NSDCFGDB</Env> 
< Env Name = 11 RETRY_I NTERVAL " > 5 < / Env > 
<Env Name= 11 RETRY_PATHMON_NAME " xReference 

Re f = 11 CommPa t hway 11 / x / Env > 

<Env Name= 11 RETRY_SERVERCLASS_NAME " xReference 

Ref = f, RetryServerClass !, /x/Env> 

<Env Name- 11 SEND_TO_AP_BY_TRAN_NBR " >NO< /Env> 

<Env Name= 11 SERVICE_TYPE " >NNP< /Env> 

<Env Name= " TCPIP_PROCESS_NAME " xReference 

Ref = "TCPIPProcess"/x/Env> 

<Env Name=" TIMEOUT ,! >1000</Env> 

< IncludeEnvSet SetName= " Error loggerSet " / > 

<SCRef PathmonEnv= " ARCHI VEPURGER__PATHMON_NAME " 

SCEnv= 11 ARCH I VE PURGER_S ERVERCLAS S_NAME " SCOb j = "NDP- 

AP"/> 

<SCRef PathmonEnv= "CLLI_UPDATE_PATHMON_NAME lf 
SCEnv= "CLLI_UPDATE_SERVERCLASS_NAME n SCObj = "NDP-CLLI - 
UPDATE "/> 

< SCRe f Pat hmonEnv= " POOL JVIANAGER_PATHMON_NAME " 
SCEnv= " POOL_MANAGER_SERVERCLASS_NAME » SCObj = "NDP-POOL- 
MGR " / > 

<SCRef PathmonEnv= " STATUSBROKER_PATHMON_NAME 11 
SCEnv= » STATUSBROKER_SERVERCLASS_NAME " SCObj = 11 STATUS - 
BROKER" /> 

<SCRef SCEnv="DMO_PROCESS_NAME" SCObj ="NDP- 
DMORSPNDR"/> 
</Object> 

<Object Name= "SCHEDULERS 

<Define Name= "JSRLJDI " xMap 
Fi 1 e= " \ SDPLAB .$ SYSTEM . ZORBB1 0 . NSDSRL "/ x /Def ine > 
<Env Name="DAYS_TO_REFRESH">l</Env> 
<Env Name="MAX_RETRIES">2</Env> 
<Env Name= " REFRESH_HOUR " > 1 0 < / Env> 
<Env Name= " RE FRESH_T I MER " > 1 9 < /Env> 
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<Env Name= " RETRY_INTERVAL " >4</Env> 

<Env Name="TD01_PATHMON"x Reference 
Re f = " CommPa t hway " / x / Env > 

<Env Name= " TD01_JSERVER" ><Ref erence 
Ref =" TD01ServerClass"/x/Env> 

<IncludeEnvSet SetName= "ErrorloggerSet " /> 

<SCRef PathmonEnv= " STATUSBR0KER__PATHMON 11 
SCEnv= " STATUSBROKERJSERVERCLASS " SCOb j = 11 STATUS - 
BROKER" /> 
</Object> 

<Object Name =" STATUS- BROKER »> 

< Argument s xOrbProf i 1 e/ >< /Argument s > 

<Def ine Name= "TCPIP^PROCESS^NAME" ><Map 
File= "\SDPLAB . $ZB02A" / x/Def ine> 

<Define Name= "_SRL_01 " xMap 
File= ,! \SDPLAB. $SYSTEM . ZORBB10 .NSDSRL" /x/Def ine> 

<Env Name= "DISABLE_FLAG 11 >OFF< / Env> 

<Env Name= " EMS_LOGLEVEL " > INFO< / Env> 

< Env Name = " EMS_TARGET "xReference 
Ref = " EmsTarget 11 / x /Env> 

<Env Name= " EVENT_CHANNEL_CONTEXT " xReference 
Ref = "NSPath" / >/StatusBrokerEventChannel < /Env> 

<Env 

Name= H EVENT_CHANNEL_FACTORY_CONTEXT" > /Event Service/NSD 
OMES</Env> 
<Env 

Name= " EVENT_CHANNEL_FACTORY_KIND " >EventChannelFactory< 
/Env> 

<Env Name="LOGID M xReference 
Ref = " ServerClaasName ,! / x /Env> 

<Env Name= "MAX_RETRIES 11 >3</Env> 

<Env Name="PROXY_PUSH_CONSUMER_CONTEXT" xReference 
Ref = "NSPath" / >/StatusBrokerProxyPushConsumer< /Env> 
<Env Name="SBMJTHREAD_COUNT">20</Env> 
< Env Name = " STD_LOGLEVEL " > INFO< / Env> 
<IncludeEnvSet SetName="CorbaSet "/> 
</Object> 

<Object Name="UCG-DMS2 50"> 

<Define Name="_SRL_01"xMap 
File= " \SDPLAB . $SYSTEM . Z0RBB1 0 . NSDSRL" /x/Def ine> 

<Env Name= !, DMO_SERVICE !l >NDP</Env> 

<Env Name="DTDFILE" xReference 
Ref = "DeployPath" /> /Rout eType Input . dtd</Env> 

<Env Name= " EMS_LOGLEVEL " >DI SABLED< / Env> 
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< Env Name = " EMS_TARGET " >< Re f e r enc e 
Ref = " EmsTarget 11 / ></Env> 

<Env Name = 11 LOG ID" ><Ref erence 
Ref = l! ServerClassName "/></Env> 

< Env Name = " MACH I NE_NAME ">< Reference 
Re f = " DMOPROCommandMachine "/></ Env> 

<Env Name= ,! NEED_DMOPRO " ><Ref erence 
Ref = "DMOPROCommandCount " / ></Env> 

<Env Name = M POOL_OWNER" >1< /Env > 

<Env Name= " PROCESS_NAME " >< Ref erence 
Re f = 11 S e r ve r C 1 a s sName " / >< / Env > 

<Env Name= !, REG_SERVICE fl >NNP</Env> 

<Env Name= 11 STD_LOGLEVEL H >INFO</Env> 

<Env Name= 11 SUBVOL_NAME " ><Ref erence 
Ref = "DMOPROCommandSubvol " / ></Env> 

<Env Name= ,t TCPIP_PROCESS_NAME'»xRef erence 
Ref ="TCPIPProcess n /x/Env> 

< Env Name = " VOLUME_NAME "xRefe r enc e 
Ref = "DMOPROCommandVolume " / x /Env> 

<Env Name= "XSLFILE" xRef erence 
Ref = l! DeployPath n />/RouteTypeStyleSheet .xsl</Env> 
</Obj ect> 

</System> 
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ENVIRONMENATAL XML FILE 
<?xml version= n 1 . 0" encoding="UTF-8" standalone= f, no ,! ?> 
<!--File Name: nanpEnvConf igTemplate .xsl --> 



•-> 



i _ . 



- - > 



<!-- Description: --> 
<!-- --> 
< i __*****★*★★★★★★★★★★★★★★★****★★★★★★★★**★*★ 

< ! - - MOD LOG - - > 

< | - - > 

<!-- Date CM# Done by Reason --> 

<! -- ====================================== 

<!-- 09/24/03 894 DBO Initial version --> 



- > 



<!DOCTYPE Environment SYSTEM "objectConf ig .dtd" > 

<Environment id= ,! D4 " > 

<PNPref ix>D4</PNPref ix> 
<Pathmon>$DV04</Pathmon> 

<DeployPath>/home2/dobryan/tw/Unif iedRouting/server/de 

ploy</DeployPath> 

<Hometerm>\SDPLAB . $VHS< /Hornet erm> 
<Volume>\SDPLAB . $USER1 . SDPD04</Volume> 
<Owner>\SDPLAB. 60, 58</Owner> 

<EnvConf igParam 
Name= II CommPathway ,, >$SCMl</EnvConf igParam> 

<EnvConf igParam 
Name= " DMOPROCommandCount " >3 0 0 < /EnvConf igPar am> 

<EnvConf igParam 
Name= n DMOPROCommandMachine n >\SDPLAB< /EnvConf igParam> 

<EnvConf igParam 
Name= "DMOPROCommandSubvol " >DMOPROT< / EnvConf igParam> 

<EnvConf igParam 
Name= 11 DMOPROCommandVolume " > $USER1 < / EnvConf igParam> 

<EnvConf igParam 
Name= "EmsTarget " >$ACNSD< /EnvConf igParam> 

<EnvConf igParam 
Name= n HostName M >10 . 74 . 110 . 15< /EnvConf igParam> 

<EnvConf igParam 
Name= "NSLocation" >http : //sdplab . corp . sprint . com : 80/pns 
d . ior < / EnvConf igParam> 

<EnvConf igParam Name= "NSPath" >/SDP- 
DEV/DV04/Unif iedRouting/ server< /EnvConf igParam> 
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< EnvConf igParam Name= " RCO lServerCl as s " >RC0 1 - 
D4 < / EnvConf igParam> 

<EnvConf igParam 
Name="ReconCommandMachine" >\SDPLAB</ EnvConf igParam> 

<EnvConf igParam 
Name= n ReconCommandSubvol " >RECDV04 < /EnvConf igParam> 

<EnvConf igParam 
Name= "ReconCommandVolume ">$USER1< /EnvConf igParam> 

<EnvConf igParam Name="RetryServerClass" >RETRY- 
D4 < /EnvConf igParam> 

<EnvConf igParam 
Name= H TCPIPProcess">$ZB02A</EnvConf igParam> 

<EnvConf igParam Name= " TDO lServerClas s " >TD0 1 - 
D4 < / EnvConf igParam> 

<EnvConf igParam 
Name= " WebLocat ion " >ht tp : / /kcsdpf wdO 0 '/Development / 04 /Un 
i f iedRout ing< / EnvConf igParam> 



<CFGMGT> 

<TSMPServer Act ive=" true " /> # if receiving 
corba requests via pathway 

<TCPServer Act ive= ,f true" /> # if receiving 
corba requests via tcp 

<FSServer Active="true"/> # if receiving 
corba requests via writeread 

<TSMPClient Act ive= H true "/> # if sending 
corba requests via pathway 

<TCPClient Active= M true" /> # if sending corba 
requests via tcp 

<FSClient Active= n true"/> # if sending 
corba requests via writeread 
</CFGMGT> 



- - > 



<!-- 

ServerClass attributes 



Name 
Object 



server class name 
object name, ref in 




NUMSTATIC for server 



MAXSERVERS for server 



cpus where the server 



PNSeed 
Priority 



the process name seed 
PRI for server class 
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LinkDepth 



LINKDEPTH for 



serverclass 



MaxLinks 



MAXLINKS for 



serverclass 



AutoRestart 



AUTORESTART for 



serverclass 



<ServerClass 

Name="NDP-AP" 

Object="NDP-AP" 

CPUList="0,l,2,3" 

ProcessCount= 11 1 " 

PNSeed= "AP" 

Priority= "160" 

LinkDepth= "16 11 

MaxLinks="16"> 
</ServerClass> 

<ServerClass 

Name = "NDP- CLL I - UPDATE " 

Ob j ect= 11 NDP -CLL I -UPDATE " 

ProcessCount= " 1 11 

PNSeed="CU" 

Priority= "160" 

LinkDepth="l" 

MaxLinks="16 n > 
</ServerClass> 

<ServerClass 

Name = ,! NDP- COMM - MGR " 

Ob j ect= " ND P - COMM - MGR " 

ProcessCount= 11 5 " 

AutoRestart="5" 

PNSeed= " CM" 

Priority= "160 11 

LinkDepth= "1"> 

<CFGMGT> 

<TSMPServer Active= fl true n /> 
<TCPServer Active=" true"/> 

</CFGMGT> 
</ServerClass> 

<ServerClass 

Name= "NDP-CORE " 
Object="NDP-CORE n 
CPUList="0 / 1,2,3" 
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ProcessCount="5 " 
Stat icProcessCount= " 1 M 
PNSeed= "CR" 
Priority= "160" 
LinkDepth= "l n > 
</ServerClass> 

<ServerClass 

Name= " NDP - DMORS PNDR " 

Ob j ect= "NDP -DMORS PNDR" 

ProcessCount=" 1 " 

PNSeed= "DR" 

Priority= "157" 

LinkDepth= "1" 

MaxLinks="16"> 
</ServerClass> 

<ServerClass 

Name= " NDP - POOL - MGR " 

Ob j ec t = " NDP - POOL - MGR '» 

CPUList="0 / l / 2 / 3 n 

ProcessCount= 11 1 " 

PNSeed="PM" 

Priority= "160" 

LinkDepth= 11 16" 

MaxLinks="16"> 
</ServerClass> 

<ServerClass 

Name =" NDP - QUERY ,! 

Ob j ec t = " NDP - QUERY " 

AutoRestart="5" 

CPUList="0,l,2,3" 

Proces sCount = " 5 " 

PNSeed= M Q0 " 

Priority= "160" 

LinkDepth= "1"> 

<CFGMGT> 

<TSMPServer Active="true H /> 
<TCPServer Active="true !l /> 

</CFGMGT> 
</ServerClass> 

<ServerClass 

Name = " NDP - REC - BACK " 
Obj ect= "NDP -REC -BACK" 
CPUList="3 / 4" 
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ProcessCount= " 1 " 
PNSeed= "EB" 
Priority= "158" 
LinkDepth= "10" 
MaxLinks="120"> 
<CFGMGT> 

<TCPServer Act ive=" true "/> 
</CFGMGT> 
</ServerClass> 

<ServerClass 

Name = " NDP - REC - FRONT " 

Object="NDP-REC- FRONT" 

CPUList="3,4" 

ProcessCount= " 1 " 

PNSeed= "EF" 

Priority="160" 

LinkDepth= "10" 

MaxLinks="120"> 

<CFGMGT> 

<TSMPServer Active=" true"/> 
<TCPServer Active="true"/> 

</CFGMGT> 
</ServerClass> 

<ServerClass 

Name =" NDP -REPORT" 

Object= "NDP-REPORT" 

AutoRestart="5" 

CPUList="0, 1, 2, 3" 

ProcessCount= " 1 " 

PNSeed="RP" 

Priority="160" 

LinkDepth= " 1 " > 

<CFGMGT> 

<TSMPServer Active=" true"/> 
<TCPServer Active="true"/> 

</CFGMGT> 
</ServerClass> 

<ServerClass 

Name = " NDP - REQUEST " 
Obj ect= "NDP -REQUEST" 
AutoRestart="5" 
ProcessCount= " 5 " 
PNSeed= "RQ" 
Priority= "160" 
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LinkDepth= M l !l > 

<CFGMGT> 

<TSMPServer Active= 11 true" /> 
<TCPServer Active="true"/> 

</CFGMGT> 
</ ServerClass> 

<ServerClass 

Name = " NDP - RS PNDR »■ 

Ob j ect= "NDP-RSPNDR" 

ProcessCount= " 1 " 

PNSeed="NR" 

Priority="160" 

LinkDepth= "16" 

MaxLinks="16"> 
</ServerClass> 

<ServerClass 

Name = "SCHEDULER" 

Ob j ect = " SCHEDULER " 

CPUList="0 / l / 2 / 3" 

ProcessCount= " 5 " 

Stat icProcessCount= " 1 11 

PNSeed="SS n 

Priority^ "160" 

LinkDepth= "1"> 
</ServerClass> 

<ServerClass 

Name= "STATUS -BROKER" 

Ob j e c t = " STATUS - BROKER 11 

ProcessCount= " 1 " 

PNSeed="SB" 

Priority^ "160" 

LinkDepth= "1" 

MaxLinks="16"> 

<CFGMGT> 

<TCPClient Active="true"/> 

</CFGMGT> 
</ServerClass> 

<ServerClass 

Name = " UCG - DMS 2 50" 
Ob j ect= "UCG-DMS250 " 
CPUList="0 / 1,2,3 " 
ProcessCount= " 5 " 
Stat icProcessCount= " 1 11 
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PNSeed= "UC M 
Priority="160" 
LinkDepth= "1"> 
</ServerClass> 

</Environment> 
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